home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 4 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.3 KB
  1. Path: news.infi.net!usenet
  2. From: nngis@norfolk.infi.net (Greg DiGiorgio)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: strange problem with strcpy()
  5. Date: 1 Jan 1996 02:49:45 GMT
  6. Organization: Customer of InfiNet
  7. Message-ID: <4c7i49$q7b@news.infi.net>
  8. References: <DKFsII.FyJ@iglou.com>
  9. NNTP-Posting-Host: h-talisman.norfolk.infi.net
  10. Mime-Version: 1.0
  11. X-Newsreader: WinVN 0.99.3
  12.  
  13. In article <DKFsII.FyJ@iglou.com>, quare@iglou2.iglou.com says...
  14. >
  15. >Some background.  tc++ 3.0 for dos.  Basically I have this routine that 
  16. >reads in files from the current directory and makes an malloc'ed array of 
  17. >structures which hold info about those files (attribs, filename/ext, size,
  18. >etc.).  More detailed info on request.
  19. >
  20. >Anyway, this routine uses a pointer to write to this 'array'.  (as in:
  21. >pointer->name, pointer->size, etc.).  strcpy(pointer->name, 
  22. >fileinfo->name) (fileinfo is the structure written to by the dos service) 
  23. >*sometimes* works, yet sometimes it will place a \0 in the first position 
  24. >of pointer->name.  for example..
  25. >
  26. >if fileinfo->name == "test.c", strcpy will place "\0est.c" into 
  27. >pointer->name.  Any clues as to how this is happening?  And no, 
  28. >pointer->name was not "test.c" before the call to strcpy().  Please... I 
  29. >beg of you... :(
  30. >
  31. >-- 
  32. >!quare 
  33. >
  34.  
  35. STRCPY is not the problem. I have worked with every version of turbo C for 
  36. DOS since V2.0 in 1988 and believe me - if you are having a problem with 
  37. STRCPY, its your code not the string library.
  38.  
  39. Now, what could cause your problem? As you know STRCPY is a dumb function 
  40. that copies bytes from whatever source address you give, up utnil it hits a 
  41. NULL to whatever destination address you give. Since you say you are using 
  42. MALLOC and/or REALLOC, my guess is that you are screwing up your pointer 
  43. arithmetic. It happens to everyone - experienced and newbie alike!
  44.  
  45. Let's assume that you have 2 vars, s1 and s2. s1 = "ABCD" and s2 = 
  46. (char)NULL. So if you "strcpy(s1,s2)" you'll get "\0BCD" in s1. If your 
  47. malloc fails, it returns a NULL which is easy enough to check. 
  48.  
  49. I know this won't answer your problem. My guess is that you need another 
  50. "set of eyes" to spot your bug. Right now, though, I don't volunteer myself, 
  51. but suggest that you put your code up in the newsgrp. Maybe not all of it - 
  52. perhaps just the part where you know it goes bad.
  53.  
  54. Good luck,
  55. Greg DiGiorgio
  56.  
  57.